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Abstract. Configurable software verification is a recent concept for ex- 
pressing different program analysis and model checking approaches in one 
single formalism. This paper presents CPAchecker, a tool and frame- 
work that aims at easy integration of new verification components. Every 
abstract domain, together with the corresponding operations, is required 
to implement the interface of configurable program analysis (CPA). The 
main algorithm is configurable to perform a reachability analysis on ar- 
bitrary combinations of existing CPAs. The major design goal during 
the development was to provide a framework for developers that is flex- 
ible and easy to extend. We hope that researchers find it convenient 
and productive to implement new verification ideas and algorithms us- 
ing this platform and that it advances the field by making it easier to 
perform practical experiments. The tool is implemented in Java and runs 
as command-line tool or as Eclipse plug-in. We evaluate the efficiency 
of our tool on benchmarks from the software model checker Blast. The 
first released version of CPAchecker implements CPAs for predicate ab- 
straction, octagon, and explicit-value domains. Binaries and the source 
code of CPAchecker are publicly available as free software. 

1 Overview 

The field of software verification is a fast growing area, and researchers contribute 
new ideas and approaches with enormous pace. The more new approaches are 
discovered, the more difficult it is to understand the essential insight or the fun- 
damental difference that makes a new approach good and better. Experimental 
evaluation is often a deciding factor for whether or not a new approach is con- 
sidered an advancement of the field. But it requires a considerable engineering 
effort to actually build the software infrastructure for evaluating verification al- 
gorithms. Adapting a suitable parser frontend and transforming the abstract 
syntax tree into a format that is convenient for verification algorithms is one 
example. The interaction with a theorem prover is yet another issue that needs 
to be considered. There are successful approaches in program analysis as well as 
in model checking, but these techniques are rarely combined; the reason being 
that it is indeed extremely difficult to combine them. Most published approaches 
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are not even comparable, because the choice of the parser frontend, the choice 
of the theorem prover, and the choice of the pointer-alias analysis algorithm in 
the corresponding tool implementation, considerably influence the performance 
and precision of the new verification algorithm. When evaluating a performance 
comparison of two approaches, it is often difficult to identify what the new ap- 
proach contributes and what is due to the different environment. In practice, it 
was so far extremely difficult to perform an experimental performance evaluation 
of one component while keeping all other components constant. 

Configurable program analysis (CPA) provides a conceptual basis for ex- 
pressing different approaches in the same formal setting. The CPA formalism 
provides an interface for the definition of program analyses, which includes the 
abstract domain, the post operator, the merge operator, and the stop opera- 
tor Consequently, the corresponding tool implementation CPAchecker pro- 
vides an implementation framework that allows the seamless integration of pro- 
gram analyses that are expressed in the CPA framework. The comparison of 
different approaches in the same experimental setting becomes easy and the ex- 
perimental results will be more meaningful (valid). The tool can be seen as a 
set of components that are loosely dependent on each other and that are easy 
to substitute. 

In many respects, CPAchecker is similar to Blast [3|. For example, we 
implemented a predicate abstraction and an explicit- value analysis [B[ . However, 
Blast has several limitations that we need to eliminate, most prominently, that 
the architecture and the design are not flexible enough to implement a pure 
CPA-based analysis. As in the Blast project already, many ideas were taken 
from Slam 

The source code, executables, and all benchmark programs for CPAchecker 
are available online at |http : //www . cs . sf u. ca/~ dbeyer/CPAchecker . The tool is 
free software, released under the Apache 2.0 license. CPAchecker is an open- 
source implementation of the framework of configurable program analysis (CPA). 
We hope that other researchers can integrate new techniques for software ver- 
ification into CPAchecker and that software-verification technology becomes 
more accessible for practitioners using this platform. 

2 Architecture and Implementation 

Figure Q] shows an overview of the CPAchecker architecture. The central 
data structure is a set of control-flow automata (CFA) (similar to control-flow 
graphs [l|), which consist of control-flow locations and control-flow edges. A lo- 
cation represents a program-counter value, and an edge represents a program 
operation, which is either an assume operation, an assignment block, a function 
call, or a function return (we do not consider more complex operations due to 
a well-known reduction called C intermediate language [3]). Before a program 
analysis starts, the input program is transformed into a syntax tree, and further 
into CPAs. The current version of CPAchecker uses the parser from the CDT0, 

1 Available at http://www.eclipse.org/cdt 
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Fig. 1. CPAchecker — Architecture overview 



a fully functional C and C++ IDE plug-in for the Eclipse platform. Our frame- 
work provides interfaces to SMT solvers and interpolation procedures, such that 
the CPA operators can be written in a concise and convenient way. Currently 
we use Simplify[1 and MathSAT^ as SMT solvers, and CSIsat0 and MathSAT 
as interpolation procedures. We use JavaBDD as BDD package and provide 
an interface to an Octago representation as well. 

The central algorithm is the program-analysis algorithm that performs the 
reachability analysis 0]. (CPAchecker actually implements CPA+, i.e., CPA 
with precision adjustment, but we skip this detail for better presentation.) The 
analysis algorithm operates on an object of the abstract data type CPA, i.e., 
the algorithm applies operations from the CPA interface without knowing which 
concrete CPA it is analyzing. For most configurations, the concrete CPA will 
be a composite CPA Q , which implements the combination of several different 
CPAs. 

In order to extend CPAchecker by integrating an additional CPA for a new 
abstract domain, only two steps are necessary. First, an entry in the global 
properties file is necessary in order to announce the new CPA for composition. 
Second, the interface for CPA needs to be implemented, and implementations of 
all CPA operation interfaces need to be provided. Figure [2] shows the interaction: 
The CPA algorithm (shown at the top in the figure) takes as input a set of 
control-flow automata (CFA) representing the program, and a CPA, which is 



2 Available at http://secure.ucd.ie/products/opensource/Simplify 

3 Available at http://mathsat4.disi.unitn.it 

4 Available at http://www.cs.sfu.ca/~dbeyer/CSIsat 

5 Available at http://javabdd.sourceforge.net 

6 Available at http://www.di.ens.fr/~mine/oct 
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Fig. 2. CPAchecker — Design for extension 



in most cases a Composite CPA. The interfaces correspond one-to-one to the 
formal framework 

The elements in the gray box (top right) in Fig. [5] represent the abstract 
interfaces of the CPA and the CPA operations. The two gray boxes at the bot- 
tom of the figure show two implementations of the CPA interfaces, one is a 
Composite CPA that can combine several other CPAs, and the other is a User 
CPA. For example, suppose we want to implement a CPA for shape analysis. 
We would provide an implementation for CPA, possible called ShapeCPA, and 
implementations for the operation interfaces on the right. If we want to experi- 
ment with several different merge operators, we would provide several different 
implementations of Merge Operator Interface that can be freely configured for 
use in various experiments. 



3 Experiments 

We report experiments in order to demonstrate that the tool implementation 
performs reasonable well on well-known benchmark examples. We pick a config- 
uration for program analysis that was previously used [5[, namely, the combi- 
nation of an explicit-value analysis and a predicate-abstraction. Explicit-value 
analysis, also known as constant propagation, keeps track of values of integer 
variables. The predicate abstraction is based on Cartesian abstraction and lazy 
abstraction [||. We run the analysis on various verification problems for simpli- 
fied versions of Windows device drivers. The verification property is always a 
safety property (reachability of a certain error location under certain variable 
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Table 1. Performance results; runtime given in seconds of processor time; the 
numbers in the column headings are the threshold values 



Program 
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> 1200.00 


525.90 


74.65 


8.43 


2.96 


cdaudio_simpll_BUG 


167.67 


88.45 


17.09 


3.28 


0.62 


diskperLsimpll 


> 1200.00 


>1200.00 
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21.19 


280.10 


floppy _simpl3 


110.38 
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11.91 


0.88 


floppy _simpl3_BUG 
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Table 2. Statistical data observed during the experiments; a dash indicates 
that the experiment was aborted after 20min; 'Preds' indicates the number of 
predicates used in the verification run, and 'Refines' indicates the number of 
refinement steps 
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values) and is thus contained in the source code. The same program name end- 
ing with a different number indicates that the same program is present with a 
different simplification applied to the source code. If the program name ends 
with "BUG" then a defect was artificially introduced into the program. 

The overall performance results obtained in our initial development phase 
of CPAchecker are satisfactory, although optimization was not the main de- 
sign goal — rather we focussed on a portable and flexible environment to be 
used for many different analysis purposes. All experiments were performed on a 
GNU/Linux (Ubuntu 8.10) x86_32 machine with an Intel Core 2 Duo processor 
and 2 GB RAM. We limited the memory for the Java virtual machine to 1.8 GB 
and set the time limit for termination to 1200 s. 

Table Q] shows the performance results for different configurations. The first 
column of the table lists the names of the programs. The next five columns 
report the runtimes for the analysis configuration where predicate abstraction 
and explicit-value analysis are used together. The threshold (the number in the 
column heading) indicates how many different explicit values where tracked for 
each variable (cf. [f| for the details). After reaching this threshold the value of 
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the variable is set to T, i.e., nothing can be said about the value of the variable 
in the explicit analysis. This might lead to an infcasible path and the predicate- 
abstraction domain discovers predicates in order to track the missing variables 
and to eliminate the infcasible program path. We experimented with five dif- 
ferent threshold values, where represents the extreme case of pure predicate 
abstraction-based analysis, and oo represents the extreme case of pure explicit- 
value analysis. Table [1] indicates that the best performance in total for this set 
of programs is achieved with a threshold of 5, which represents a good tradeoff 
between the expensive but abstract predicate abstraction and the simple but 
exploding explicit- value analysis. It is interesting to observe that pure predicate 
abstraction is not tractable for some of the experiments (time out reached) . 

Table [5] shows the number of predicates and the number of refinement iter- 
ations needed to obtain the verification result. Surprisingly, many facts can be 
tracked by explicit values, and thus the number of predicates in the abstract- 
successor computations is drastically reduced. Also, the number of refinements 
that are necessary to discover predicates is significantly reduced (note that many 
different refinements might discover the same predicate for different locations). 
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